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Abstract 

As the substation communication world searches for the 
“Promised LAN”, it would be helpful to have a roadmap 
to give direction to the search. Many are the expectations 
of a LAN flowing with data and able to connect with any 
Intelligent Electronic Device (IED) that was ever made. 
Such expectations must be tempered with the cost and 
complexity of achieving them. This paper presents an 
outline of the communication requirements of the myriad 
of IED’s in existence in the substation today as well as the 
expectations of what second generation microprocessor 
based devices might be able to do. Requirements will 
focus on language issues, system capabilities, 
performance requirements, external interfaces, 
environmental, and quality issues. Some attention will 
also be given to the architecture of a solution and some 
guidelines as to how this structure might be built. 


Introduction 

From the introduction of processor based devices, we have 
had the ability to communicate with these devices. The 
ability to communicate gives added value to the IED and 
as such, has hastened their implementation. As time has 
gone on, we have watched communities of these devices 
sprout up in the substation - typically with no concerted 
attempt to inter-communicate much less interoperate. As 
a result, a veritable “Tower of Babble” has arisen inside 
the substation. Attempts to date to achieve some 
semblance of common communication have focused 
around “Rosetta Stone” solutions whereby a translation 
module of software is located between the IED and host 
computer. Although this technique achieves today’s 
goals, translation hardware is usually required and 
creation of the translation module can be costly and time 
consuming. Another aspect is that revisions and 
generations of new IED’s have become a frequent 
occurrence demanding constant “stone cutting” and 
“chipping” of translation communication software. 
Newer IED designs implement faster communication 
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rates, have more data to communicate, and are capable of 
performing some programmable logic functions. 


In view of future capabilities and a continuing 
proliferation of IED’s in the substation, a cry has come 
from the utility community to create a framework for not 
only common communication but an architecture that will 
provide for interoperation. Interoperation implies the 
ability to “plug and play” and also to be able to “share” 
data and functions. As an example, a protective relay 
may be required to provide a “check synchronism” 
function which requires the magnitude and phase angle 
comparison of two voltages. The relay performing the 
function may have intrinsic access to only one voltage. 
The other voltage may be available from another device in 
the substation . An interoperable system could then 
negotiate for access to the other voltage and as such, 
avoid all the overhead involved in direct wiring. 


Integration Benefits 

As substation integration becomes a reality, there are 
numerous benefits that can be realized. With data 
sharing, wiring between devices can now be minimized. 
Distributed data acquisition now becomes the foundation 
of substation integration. Traditional hardware devices 
such as the Remote Terminal Unit and the Digital Fault 
Recorder now become primarily functional entities that 
draw on other IED’s for their data. Interoperation 
permits distributed functionality, that is, the data and/or 
the decisions needed for a particular function may reside 
among multiple IEDs. 


Such changes in the substation design paradigm can be 

measured both quantitatively as well as qualitatively. 

Quantitatively speaking, substation integration has the 

potential for the following savings [1]: 

e Elimination of the station fault recorder & wiring 

e Elimination of the station Sequence of Events 
recorder & wiring 

e = Minimization of RTU wiring 


e Minimization of Breaker Wiring 


Qualitatively, the integrated system brings with it: 

e Reduced O&M through “Real Time” condition 
monitoring 

e 100% redundancy in fault recording 

e Rapid fault location 

e Integrated Protection & Control 


and many others. 


Requirements Document Creation 

Through the funding of EPRI and in conjunction with 
numerous IEEE Working Groups and the MMS Forum, 
work has begun on a top down design to define the 
requirements for an integrated Protection, Control, and 
Data Acquisition communication system. The 
requirements document (open to the public for review and 
comment) is intended to be the foundation of an open 
protocol definition that will focus on peer to peer 
communication in the substation and is expected to have 
extensions to other areas of power system communication. 


The software architecture is based on the International 
Standards Organization (ISO) seven layer Open System 
Interconnect (OSI) model for communication protocols 
[2]. This model breaks a protocol down into 7 
independent functional entities that can be linked together 
(depending on the functional requirements) to create a 
protocol definition. In the substation environment, there 
are three layers that are applicable and only the bottom 
one is of interest to the utility. Figure 1 illustrates this 
shortened stack of protocol agreements. The bottom layer 
is know as the “Physical” layer and defines how one 
connects into the system. For example, do I connect a 
fiber optic cable or a pair of copper wires. The middle 
layer in this Substation stack is the Data Link Layer 
which defines how the data is packaged. 


The top layer of this model is known as the Application 
layer. It is at this level at which the user or user’s 
program interfaces with the communication protocol and 
ultimately other IED’s. It is also at this level where the 
greatest challenge lies as the development of a common 
language is required here in order to interoperate among 
the various IED’s. The challenge here can be equated to 
communication through the spoken language. As a 
simple model, the basic building blocks of most 
languages are nouns and verbs. Combinations of these 
nouns and verbs express requests, issue commands, and 
exchange information. The reason we can communicate 
together is because we have all learned the same nouns 





and verbs in the same language and can turn to a 
dictionary to describe the words we do not understand. 


The requirements definition process mandated some 
technique whereby the various information items and 
functions of the IED’s could be described and where that 
description could be shared by all. A device description 
technique known as Object Oriented Methodology 
(OOM) has been adopted as a fundamental requirement 
in the overall design process. OOM provides a tool 
whereby the “nouns” and “verbs” that describe an IED 
and its functions can be created or “abstracted”. The 
“nouns” or the information contained within the IED are 
known as the “attributes” of the object and the “verbs” or 
what the IED can do to the data are known as the 
“methods”. For example, a relay will make 
measurements of voltage and current and compute watts 
and vars. The attributes for this one aspect of a relay 
would be: Volts, Amps, Watts, and Vars. Subsequently, 
one of the methods would then be “Compute”. 


In establishing the groundwork for abstracting the 
numerous attributes and methods of the substation 
IED’s, a model of the model or a “meta” model was 
created. This “meta” model defines data that would be 
present in any type of IED. There is a standard diagram 
that is used to construct the object model which is 
illustrated in Figure 2 via the “meta” model for an IED. 


APPLICATION 
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Figure 1 
3 Layer Protocol Stack 


The top line is the name of the object being described 
which in this case is a Virtual Device object. The 
middle section is the “attribute” list and the bottom 
section is the “methods” list. Clearly, there are more 
attributes and methods needed to describe, for example, 
a relay object. The beauty of the object modeling 
approach, however, is that various attributes can be 
grouped in classes and then linked back to the base 
model. This technique allows the addition of new 
attributes without having to re-do the definitions and 
assignments of the previously defined attributes. 


Work is now in progress in the MMS Forum and the 
IEEE Power System Relay and Substation Committees to 
define standard or public object definitions. Common 
items such as Voltage, Current, Watts, Vars, etc. can 
very readily be agreed upon as far as a standard 
definition goes. It is inevitable, however, that each 
manufacturer’s IED will have attributes that are new or 
unique to that IED. These “vendor specific” attributes, 
being otherwise unknown to anything else in the system, 
need a mechanism to define what they are. 


As such, the concept of “self defining data” was included 
in the requirements document. In response to the 
standard query “who are you?’, an IED would be 
required to download its object definition, complete with 
a data dictionary, to define any “vendor specific” 
attributes. In this manner, an RTU function could 
automatically query all IED’s in the substation and 
compile a standard list of the information it is required 
to obtain. 


System Requirements 

System functionality was based on application 
requirements of existing relaying schemes such as 
breaker failure, reclosing, fault recording, metering, and 
sequence of events recording. In so basing the thinking, 
system capabilities, performance requirements, facility, 
environmental, and external interfaces were specified to 
meet these application requirements. The various 
elements fall out as follows: 


System Capabilities 


Addressing - each data source and receiver need to be 
identified by and respond to a unique address. One issue 
to be resolved is whether all IED are assigned a unique 
address in the universe similar to the addressing done on 
Ethernet boards. 


Broadcast - the ability of a pre-specified group of 
receivers to respond to a common address. This feature 


is useful for re-triggering multiple IED’s when one IED 
is triggered for a data capture. Broadcast transfers can 
reduce the total traffic loading on the communication 
system, however, broadcast messages cannot be 
acknowledged and thus cannot be used when 
confirmation of a message is required. 


Multicast - a variation of Broadcast whereby multiple 
addresses can be specified to receive a message. 


Directory Services - automatically creates and 
maintains a map of all network resources. This function 
is critical for automatically configuring the network. 


Negotiation - the ability to query the availability of 
required system data elements and methods. For 
example, the IED doing check synchronism may need to 
negotiate for the availability of the voltages on the 
network. 


File Access, Transfer, and Management - the 
transparent transfer of data files between IED’s as part 
of the data management function of the various IED. As 
processor power increases, the number and size of these 
data files will increase in kind. 


Virtual Device 


Devide_ID 
Device_Type 
Device_Description 
Device_Make_Model 
Device_Communication_Address 
Circuit_Identifier 
Circuit_Voltage 
Circuit_CT_Ratio 
Local_Remote_State 
Tag_Type_Permitted 
Active_Tag_Array 
Load 

Device_Rating 


Set_Attribute 
Get_Attribute 
Test 

Reset 





Figure 2 
Standard Object Model 


Network Access - this is how an IED obtains its ability 
to respond to a query or to offer and unsolicited message. 
There are two primary access methods for consideration: 


Peer to Peer - wherein any JED in the substation 
can communicate with any other IED. Peer to 
peer can take place either through controlled 
access (such as a token-passing scheme) or via 
random access (such as the listen before you talk 
access of Ethernet). A variation of either of these 
access methods is the ability to permit “priority 
access”, that is, the ability to interrupt a message 
transfer with a higher priority message. 


Master / Slave - wherein IED’s in the system 
only responds to requests from a master device. A 
variation of this occurs where there are multiple 
masters - each capable of peer to peer 
communication. 


Network Management - this shall provide the network 
manager up to the minute information on the network 
size, operating conditions, alarms, system loading, and 
error statistics. This function shall also be used to add 
new devices to the network. 


System Performance Requirements 

To implement the various functions that are envisioned 
for implementation on a substation LAN, the following 
performance requirements have been defined: 


Time Synchronization - Two levels of time 
synchronization have been identified in the substation. 
For general purpose synchronizing, a time accuracy of 
Ims +0.1ms was selected. For higher accuracy data, 
such as phasor measurement and data sharing, an 
accuracy of lusec +0.5usec has been chosen. 


Timing Constraints - data transfers intervals were 
divided into three categories, namely, “High Speed” for 
data transfer requirements less than 10ms, “Medium 
Speed” for transfer requirements greater than 10ms and 
less than Isec, and “Low Speed” involving data transfer 
rates greater that 1 sec. Note: At this time, the 
requirement for the exchange of High Speed sample data 
was not a priority and as such was not addressed by this 
document. 


Delivery Times - the time allowed to transfer any 
routinely updated data element from a sending to a 
receiving IED must be less than the average update 
interval. 


System Quality Requirements 

The following elements deal with the question of “how 
well” the system performs its tasks not only today but 
also tomorrow. 


Scalability - the protocol profile chosen should be robust 
enough for operation today and should have a clear 
migration path to increased performance in the future. 


Reliability - the system shall provide error free data 
transmission, shall possess “fail soft” recovery from link 
congestion, and shall provide support for link and/or 
equipment redundancy. 


Transportability - the system software shall be 
migratable to multiple hardware, software , and network 
operating environments and support the object 
management structure chosen as well as its expansion. 


Flexibility and Expandability - the system shall have 
adequate address space for today and moving into the 
future. It shall easily detect and add on new devices 
hooked into the LAN. It shall support on-line network 
and IED system upgrades. 


Security and Integrity - provisions shall be available to 
prevent unauthorized access, provide management of 
user authorization, support for encryption, and 
automated virus detection. 


The Number of the Beast 

As the requirements lead to a proposed solution, one of 
the questions that arises is “how big” or “how fast” is the 
size of the animal that is being defined? Taking a stab at 
some numbers for two different system requirements, the 
results roll up as follows: 


For a “Medium Speed” system that is addressing 32 
IED’s once every second and transferring up to 256 bytes 
each second, an aggregate throughput of about 65kbps 
would be required. 


For a “High Speed” system also addressing 32 IEDs on a 
Token Passing network but with a smaller data packet of 
64 bytes and a response time of 4ms (including any turn- 
around time), an aggregate system throughput of about 
4Mbps would be required. The benefit of “Priority 
Access” can be seen here in that similar response time 
can be achieved with a lower data rate. 


Implementation 

The current institutional efforts to define structure for the 
new digital universe must be accompanied by the rapid 
development of implementation vehicles if the industry is 
to advantage, rather than succumb to the new technology. 
If the current standards work is to have more than 
historical value it must be accelerated to synchronize with 
the pace of technological change, be viewed as a real time 
consensus definition of best practice, and be connected to 
an implementation path embraced by the utility industry. 


Utilities are driven by the need for increased productivity 
in the emerging competitive environment, while at the 
same time are undergoing personnel reductions which 
weaken their ability to define and implement integrated 
automation systems to improve productivity. Functionally 
fragmented institutional structures are evolving to support 
these integrated system goals, but the trauma of such 
major changes further inhibits internal solutions. 


Figure 3 illustrates the principal elements of substation 
integration and automation systems. The integration 
function has, in today's environment, typically moved 
outside of the utility box. The Integrator's challenge is to 
define best fit / best value solutions tailored to the specific 
utility's goals. In this consulting role the Integrator is 
expected to develop specifications for open systems with 
maximum flexibility for growth. His role can be 
expanded to identify the supplier of products and services, 
layout the program, manage the program, or take turnkey 
responsibility, as well as providing ongoing support and 
services. 


The IED suppliers provide protection or monitoring based 
intelligent digital devices which are performance / cost 
optimized in a rapidly changing competitive market. The 
IED's also provide the data acquisition and control 
interface with the power system at the substation. 


The Software suppliers provide custom software 
interfacing, drivers and control functions to integrate the 
IED's and provide the required system functions. The 
Integration Equipment includes the substation control 
and interfacing equipment such as Programmable Logic 
Controllers (PLC's) Personal Computers (PC's), Remote 
Terminal Units (RTU's), and associated communication 
equipment. 


The value to the utility of being able to implement open 
systems which meet current and future requirements with 
interoperable elements is obvious. The alternative of a 
single supplier providing all elements integrated into a 
closed system has generally not been acceptable to the 


utility industry. Several other approaches are emerging 

which include: 

e Combinations of the Software supplier and the 
Integrator 

e The IED supplier with the Software supplier 

e The integration Equipment supplier with the 
Integrator 

and so on. In the absence of at least an appropriate de 

facto standard embraced by all the often competing 

elements, the solutions will continue to be somewhat 

cumbersome, inflexible and costly. 


The two essential aspects of realizing the benefits of the 
application of digital technology to substation and power 
system automation are: First; a fast track commitment by 
the utilities to sponsor and support the definition of open 
standards for integration; and Second; the development 
and utilization of Integrators who effectively implement 
these emerging standards. 


One example of the possible ways in which this could be 
accomplished would be the utilization of existing utility 
organizations such as EPRI to establish system 
integrators which, because of their utility sponsorship, 
would implement the preferred standards, represent the 
utilities, and strongly influence the support of the related 
hardware and software suppliers. Various other proactive 
utility initiatives would appear to be worth considering. 
The screens for such initiatives might include: 


e support by a significant number of utilities 

e a possible equity position by the sponsoring utilities 

e a strong linkage with the continuing "standards" 
activity 

e a strategy that allows customizing for individual 
utilities 

e operational control at the Integrator with an advisory 
board representing the sponsoring utilities 

e the assignment of key utility personnel to the 
Integrator during a project. 


The alternative of waiting to see what becomes available 
does not look very attractive for the utility. 


Conclusions 

The search for a common communication platform in 
the utility industry is becoming acute being driven by the 
proliferation of communicating Intelligent Electronic 
Devices. A “top down” approach to solving the 
communication problem has been sponsored by EPRI. 
This effort has resulted in the creation of a requirements 
document that is open to the public for review. A 
summary of the basic requirements is presented. The 


heart of the requirements document is the use of Object 
Oriented Methodology as the tool to create a common 
IED communication language. This effort will only be 
effective if there is a concerted effort between the various 
industry players to quickly bring this technology to 
practice. 
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